home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / diskmags / 0022-3.564 / dmg-0085 / 413.txt < prev    next >
Text File  |  1997-04-16  |  10KB  |  247 lines
  1. =========================================================================
  2.  
  3. INFO-ATARI16 Digest         Thu,  5 Apr 90       Volume 90 : Issue  413
  4.  
  5. Today's Topics:
  6.                            Amiga/Atari help
  7.                       CurrentNotes at Terminator
  8.                   HD Backup (a summary of responses)
  9.                      Help! My Hardware is Dying!
  10.                  How to create a senseless flame war
  11.                 Let's hear more about Toronto, Please!
  12.                         Sozobon fix for Gemini
  13.                          vortex PC emulation
  14. ----------------------------------------------------------------------
  15.  
  16. Date: 5 Apr 90 21:35:23 GMT
  17. From: oliveb!amiga!cbmvax!daveh@apple.com  (Dave Haynie)
  18. Subject: Amiga/Atari help
  19. Message-ID: <10626@cbmvax.commodore.com>
  20.  
  21. In article <10365.2619c11a@zeus.unomaha.edu> fh007@zeus.unomaha.edu writes:
  22.  
  23. >  The amiga 3.5 has 880k where the Atari has about half.
  24. >                                       Bob
  25.  
  26. Well, that's not quite true.  Both the early Mac and the early ST supported
  27. 1 sided disks, which gave them 400K and 360K, respectively.  I don't know
  28. enough about each market to know how prevalent those formats are anymore, but
  29. I suspect the 800K Mac disks and 720K ST disks are far more common today.
  30.  
  31. The mechanisms used for each format are different between machines.  The ST
  32. uses an IBM-type disk controller and give you a format that's physically and
  33. logically almost the same as the IBM 3.5" format.  Physcially, that's an MFM
  34. encoding with 9 sectors/track, 2 heads, and 80 tracks.  The Mac uses a GCR
  35. format with variable angular density, kind of like a 1990s CBM 1541, to give
  36. you 800K per disk.  Amiga uses the same MFM encoding as the IBM/ST machines,
  37. but it works on a track vs. sector basis.  Without requiring any spacing
  38. between sectors, the Amiga fits 880K per disk, using 11 [logical] sectors
  39. per track, rather than the MS-DOS setup which uses 9.  That's why Amigas have
  40. no trouble reading MS-DOS or ST 3.5" disks.
  41.  
  42. --
  43. Dave Haynie Commodore-Amiga (Systems Engineering) "The Crew That Never Rests"
  44.    ?uunet|pyramid|rutgers?!cbmvax!daveh      PLINK: hazy     BIX: hazy
  45.                     Too much of everything is just enough
  46.  
  47. ------------------------------
  48.  
  49. Date: 5 Apr 90 22:18:48 GMT
  50. From: umich!terminator!terminator.cc.umich.edu!weiner@CS.YALE.EDU  (Jeff Weiner)
  51. Subject: CurrentNotes at Terminator
  52. Message-ID: <1990Apr5.221848.27399@terminator.cc.umich.edu>
  53.  
  54. Hi everyone,
  55.  
  56. Installment #2 or currentnotes stuff is now available on terminator
  57. in the ?atari/magazines/curnotes directory.
  58.  
  59. It has some past issues indexes,various columns including St Update,
  60. and the table of contents from the past three issues.
  61.  
  62. For more info, get ahold of either myself or John Barnes,
  63. (johnbarnes@enh.nist.gov).
  64.  
  65. Thanks and have a swell day,
  66.  
  67. Jmw
  68.  
  69.  
  70. ------------------------------
  71.  
  72. Date: 5 Apr 90 17:50:55 GMT
  73. From:
  74.  snorkelwacker!usc!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hplsla!andyc@tut.
  75.  cis.ohio-state.edu  (Andy Cassino)
  76. Subject: HD Backup (a summary of responses)
  77. Message-ID: <5440112@hplsla.HP.COM>
  78.  
  79. | >I've had Diamond Back for a while now. I think it might be what you are
  80. | >looking for. It uses the archive bit correctly, you can set it to compress
  81. | >files, and it seems faster than Turtle, though I haven't sat down and made
  82. |
  83. | Where can one find this program?
  84. |
  85. | Steven W. Klassen                       +-----------------------------+
  86. | Computer Science Major                  | Support the poor...buy fur! |
  87. | University of Waterloo                  +-----------------------------+
  88. | ----------
  89.  
  90. I have seen Diamond Back advertised by Joppa, MicroTyme, etc, but
  91. I bought my copy at a local dealer, who desperately needs the business.
  92.  
  93. Disclaimer: The opinions expressed herein are those solely of the author,
  94.             who has no pecuniary interest in the companies, products,
  95.             or publications mentioned above.
  96.  
  97.     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  98.     % Andy Cassino                                                  %
  99.     % uucp: hplabs!hplsla!andyc  domain: andyc%hplsla@hplabs.hp.com %
  100.     % Hewlett-Packard              Lake Stevens Instrument Division %
  101.     % 8600 Soper Hill Road                   Everett, WA 98205-1298 %
  102.     % (206) 335-2211                                                %
  103.     %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  104.  
  105. ------------------------------
  106.  
  107. Date: 6 Apr 90 00:39:19 GMT
  108. From:
  109.  zaphod.mps.ohio-state.edu!brutus.cs.uiuc.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!
  110.  uxa.cso.uiuc.edu!dbr00467@tut.cis.ohio-state.edu
  111. Subject: Help! My Hardware is Dying!
  112. Message-ID: <46300090@uxa.cso.uiuc.edu>
  113.  
  114. I have been having a lot of hardware problems lately.  A color monitor died,
  115. my mouse port on my 1040ST is really flakey and I have a couple of external
  116. disk drives laying around which aren't really functional.
  117.  
  118. What I need is some information on places where I can get some of this repaired.
  119. Preferably somewhere around St. Louis.  Alternatively, I would like to know
  120. how to get a hold of Atari to obtain this information.  Any help will be
  121. greatly apprectiated!
  122.  
  123. Please send any responses via E-Mail to the address below.
  124.  
  125.                                                 Don Roberts
  126.                                                 dbr00467@uxa.cso.uiuc.edu
  127.  
  128. ------------------------------
  129.  
  130. Date: 5 Apr 90 21:28:31 GMT
  131. From: oliveb!amiga!cbmvax!valentin@apple.com  (Valentin Pepelea)
  132. Subject: How to create a senseless flame war
  133. Message-ID: <10625@cbmvax.commodore.com>
  134.  
  135. In article <1985@naucse.UUCP> tar@naucse.UUCP (Tim Roeder) writes:
  136. >In article <10607@cbmvax.commodore.com>, valentin@cbmvax.commodore.com
  137. >(Valentin Pepelea) writes:
  138. >>
  139. >> Sometimes computer wars are initiated by users who have an inferiority
  140.  complex
  141. >> about their computers and therefore get defensive. But most often they are
  142. >> created by users who simply never took a good look on the other side of the
  143. >> fence. Let's analyse such a typically uninformed poster...
  144. >>
  145. >
  146. >While uninformed users are generally quite a pain, I see little need to waste
  147. >bandwidth with such an analyzation.
  148.  
  149. My apologies, indeed I made a mistake. I initially posted my article with the
  150. intention of demonstrating how computer wars can be accidentally started if we
  151. post messages about other computers when we are uninformed about them. In my
  152. attempt to embellish the article I transformed it into another senseless
  153. flame.
  154.  
  155. Now you know that flame wars are created by:
  156.  
  157. 1. People who are uninformed and therefore accidentally start it.
  158. 2. People who do not know when to shut up.  :-(
  159.  
  160. Valentin
  161. --
  162. The Goddess of democracy? "The tyrants     Name:    Valentin Pepelea
  163. may distroy a statue,  but they cannot     Phone:   (215) 431-9327
  164. kill a god."                               UseNet:  cbmvax!valentin@uunet.uu.net
  165.              - Ancient Chinese Proverb     Claimer: I not Commodore spokesman be
  166.  
  167. ------------------------------
  168.  
  169. Date: Thu, 5 Apr 90 20:19 EST
  170. From: JOHNBARNES@ENH.NIST.GOV
  171. Subject: Let's hear more about Toronto, Please!
  172.  
  173. The Posting on the Toronto Convention by Brandon Brooks was fine as far as
  174. it went, but it would be nice to know more.
  175.  
  176. 1.) How many people came?
  177.  
  178. 2.) Were the 5 guys from Atari all from Atari Canada?
  179.  
  180. 3.) What about some of the seminar topics?  The preliminary announcement
  181.      included one on a hypertext product, which I am keenly interested in.
  182.  
  183. 4.) How many vendors were there?  Who were they?
  184.  
  185. 5.) Were there any third-party hardware products of particular interest?
  186.  
  187. It would be nice to have a post with just the facts, please. No need
  188. for an analysis of Atari's market and advertising strategies.  These
  189. topics get more than enough bandwidth already.
  190.  
  191.  
  192. ------------------------------
  193.  
  194. Date: 6 Apr 90 00:44:17 GMT
  195. From: uupsi!ncs.dnd.ca!balkwill@rice.edu  (R. J. Balkwill)
  196. Subject: Sozobon fix for Gemini
  197. Message-ID: <771@ncs.dnd.ca>
  198.  
  199. To all who have problems running Sozobon-built programs under Gemini.
  200. Do not despair.  The real problem is in jas, the Sozobon assembler.
  201. My memory is a little shaky here but after more than a few minutes
  202. investigation I discovered the following:
  203.  
  204. 1.  Gemini uses the xArg convention for passing arguments to programs
  205. and Sozobon startup code honours this.  Gulam and most other shells do
  206. not make an xArg entry in the environment so certain portions of your
  207. startup code are never executed when calling from those.
  208.  
  209. 2.  The section that deals with xArg passing invokes either memcpy or
  210. lmemcpy from dlibs.
  211.  
  212. 3.  Although the source for these functions looks ok the jas assembler
  213. generates erroneous code for some bit-oriented instruction (btst?)
  214. therein.  Hence your startup code walks into trash of jas' making.
  215.  
  216. The Solution - either reassemble the memcpy.s and lmemcpy.s functions
  217. with a compatible assembler, or write tiny versions of your own either
  218. in assembler or C, compile them and add them to dlibs replacing the
  219. old versions.
  220.  
  221. PS - I love both Gemini and Sozobon - add in Gulam and life is fun!
  222. ---
  223. Bob
  224.  
  225. ------------------------------
  226.  
  227. Date: 5 Apr 90 17:03:50 GMT
  228. From: mcsun!unido!gmdzi!focke@uunet.uu.net  (Stefan Focke)
  229. Subject: vortex PC emulation
  230. Message-ID: <2179@gmdzi.UUCP>
  231.  
  232. I wrote a letter to vortex. If I get an answer, I will post it.
  233.  
  234.  
  235.  
  236. -------------------------------------------------------------------
  237.  
  238. Stefan Focke                  Tel. 02241-14-2265
  239. GMD-Z2.W                      e-mail: focke@gmdzi.uucp
  240. Postfach 1240                         focke@gmdzi.gmd.de
  241. 5205 St. Augustin 1                   ...!?uunet!mcvax!?unido!gmdzi!focke
  242.  
  243. ------------------------------
  244.  
  245. End of INFO-ATARI16 Digest V90 Issue #413
  246. *****************************************
  247.